home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / C++ A'Link Files / Jan 91 / CPlus.Dev$ 1⁄11⁄91 / 0252-HandleObject Derivat-Jan91 < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.2 KB  |  47 lines  |  [TEXT/GEOL]
  1. Item    0687081                         11-Jan-91        10:41PST
  2.  
  3. From:   BJERKE.M                        Bjerke, Mark
  4.  
  5. To:     D3554                           Discovery SW Int'l, Rick Ross,PRT
  6.         CPLUS.DEV$                      C++ Interest List--Developers
  7.         CPLUS.APPLE$                    C++ Interest List--Apple Employees
  8.  
  9. Item forwarded by       PERRY.G      to CATHERS 
  10.                                         PHIL.TH 
  11.  
  12. Item forwarded by       UK.DTS       to HYPERVIEW 
  13.  
  14. ------------------------------------------------------------------------------
  15.  
  16. Sub:    HandleObject Derivations
  17.  
  18. To whom it may concern,
  19. O.K. as we all know MPW C++ has a built in type 'HandleObject' that was
  20. designed to simplify the use of handle based objects, i.e. you use them exactly
  21. as you would a ptr based object ( no need to dereference the handle twice for a
  22. method call etc..). Normally 'operator new' does ptr based allocation so it was
  23. overloaded in 'class HandleObject' to do handle based allocation. Since we do
  24. not publish the interface for 'class HandleObject' we could not expect users to
  25. know that they needed access to the public interface of 'HandleObject' to
  26. access 'operator new', so the compiler did not enforce the access rules in the
  27. case of 'class HandleObject' ONLY. The problem is that this is broken in load /
  28. dump in the case of doing a PRIVATE derivation from HandleObject. In that case
  29. we do enforce the rules and complain that 'operator new' is not now accessible
  30. owing to the fact that the public interface of 'HandleObject' is now private.
  31. THIS IS A BUG, and we will fix it, the way to get around it is to do a PUBLIC
  32. derivation. I'm going to make sure the examples are changed since this is not
  33. very friendly to new users of C++.  The compiler does issue a warning which
  34. should be taken seriously:
  35. '# warning:  base foobar private by default: please be explicit ``: private
  36. foobar'
  37.  
  38. i.e. the compiler suspects that the user may be doing a 'private derivation' by
  39. accident not knowing the implications to the derived class. I suspect that use
  40. of the keyword 'private' will be mandatory in C++ in the future.
  41.  
  42. Please report any bugs via apple link: CPLUS.BUGS
  43.  
  44. regards
  45. mark bjerke -- C++ Team
  46.  
  47.